%
%  untitled
%
%  Created by Ed on 2011-01-08.
%  Copyright (c) 2011 __MyCompanyName__. All rights reserved.
%
\documentclass[]{article}

% Use utf-8 encoding for foreign characters
\usepackage[utf8]{inputenc}

% Setup for fullpage use
\usepackage{fullpage}

% Uncomment some of the following if you use the features
%
% Running Headers and footers
%\usepackage{fancyhdr}

% Multipart figures
%\usepackage{subfigure}

% More symbols
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{latexsym}

% Surround parts of graphics with box
\usepackage{boxedminipage}

% Package for including code in the document
\usepackage{listings}

% If you want to generate a toc for each chapter (use with book)
\usepackage{minitoc}

% This is now the recommended way for checking for PDFLaTeX:
\usepackage{ifpdf}

%\newif\ifpdf
%\ifx\pdfoutput\undefined
%\pdffalse % we are not running PDFLaTeX
%\else
%\pdfoutput=1 % we are running PDFLaTeX
%\pdftrue
%\fi

\ifpdf
\usepackage[pdftex]{graphicx}
\else
\usepackage{graphicx}
\fi
\title{Summary}
\author{Eduardo Gutarra Velez}

\begin{document}

\ifpdf
\DeclareGraphicsExtensions{.pdf, .jpg, .tif}
\else
\DeclareGraphicsExtensions{.eps, .jpg}
\fi

\maketitle

\section{Dimensional Modeling} % (fold)
\label{sec:dimensional_modeling}

Dimensional modeling is a technique of logical design for structuring data so that it is intuitive to business users and delivers fast
query performance. They are often considered the more appropriate models for OLAP applications as opposed to normalized. The normalized
models we talk about, go up to the third normal form (3NF). Industry also refers to them as 3NF models or entity-relationship (ER)
models. These models seek to reduce redundancies, and are considered better for transactional processing or OLTP applications.

Normalized models and dimensional models contain the same information, but are structured differently. The key difference between them
is the degree of normalization. While normalized models are completely normalized to 3NF, dimensional models normalize some tables to
2NF and others to 3NF. Dimensional modeling divides the information into measurements and context. The measurements are captured by the
organizations business processes and are usually numeric; they are called the facts. The context is represented by the dimensions which
help answer the questions of who, what, when, where, why and how of a measurement. Dimensional models may be stored as star schemas or
cubes. When stored in a relational database platform, they are called star schemas, and when stored in an OLAP structure they are called
cubes.

Dimensional models are applied in three important areas: Datawarehouses, Online-Analytical processing (OLAP), and data mining. They also
have important benefits for business intelligence which include understandability and query performance among others. Dimensional models
are often easier to understand than normalized models. Their design allow users to disregard irrelevant dimensions. Query performance is
a second benefit that comes through dimensional modeling. The number of join operations is greatly reduced when using a dimensional
model. Furthermore, the query plan can be improved through joins performed in a dimensional model, known as ``star joins''. Star joins
may be performed faster through indexing or result set size prediction.

\subsection{Fact Tables} % (fold)
\label{sub:fact_tables}

In a dimensional model, fact tables are normalized to 3NF because the related context is moved to dimensions. The dimension tables are
then denormalized to flat dimensional tables. These tables resemble 2NF tables with many low cardinality descriptors. Fact tables are
comprised of facts which are numeric measurements that represent a specific activity. The facts in a Datawarehouse can be of three types:
\begin{itemize}
	\item \emph{Events}, which model real-world events where one fact represents the same instance of an underlying phenomenon. 
	\item \emph{Snapshots}, which model the changes in an entity's state throughout time. An example of this could be inventory or the number of users in a website.
	\item \emph{Cumulative snapshots}, which aggregate information on activity up to a certain point in time.
\end{itemize}
Fact tables express a many to many relationship with each dimension. The fact table contains a foreign key for each dimension, that
allows it to integrate its information with that of the dimension. Fact tables are also characterized by a multipart key made up of
foreign keys from associated dimension tables in a business process. Each foreign key in the fact table has to match to a unique
primary key in the corresponding dimension table. The primary key of the fact table is typically a subset of the dimension foreign keys
and/or degenerate dimensions.

Facts have a certain granularity that is determined by the degree of measurement used. As an example, one may think of different degrees
of measurement for a period of time such as day, month or year. The lowest grain or finest granularity is the day while the highest
grain or coarsest granularity is the year. The measure of a fact consists of two components: the fact's numerical property, and a
formula that allows simple aggregation of several finer measure values into one. Measures can be of three types:
\begin{itemize}
\item \emph{Additive measures}, which may be meaningfully combined along any dimension.
\item \emph{Semi-additive measures}, which may not be combined along one or more dimensions.
\item \emph{Non-additive measures}, which may not be combined along any dimension, usually because the chosen formula prevents combining lower-level averages
\end{itemize}

% subsection fact_tables (end)

\subsection{Dimensions} % (fold)
\label{sub:dimensions}

Unlike the fact tables which are comprised of just keys and numeric measurements, the dimension tables are filled with big and bulky descriptive attributes.
These attributes are useful for constraining queries and labeling query result sets. The dimensions provide the context for the facts through their attributes.
They are used for selecting and aggregating data at a desired level of detail. They are often organized into containment-like hierarchies of numerous levels.
Each dimension represents a level of detail. For example, the place dimension can be analyzed at an attribute level of country, province/state, or city. Each of
these levels represents a different granularity for the fact rows. These different dimension levels can be kept in the same table, thus maintaining a star
schema. However, the dimensions in a star schema can be further normalized forming snowflake schemas. Snowflake schemas contain one table for each dimension
level avoiding redundancy. Kimball does not recommend this degree of normalization but he notes that they may be advantageous in some situations.

Dimension rows are uniquely identified by a single key field. Kimball suggests that the dimension primary keys should be simple integers assigned in consecutive
sequence starting with 1. Sometimes, these numbers act as a surrogate key for the dimension, and while they are meaningless they have important advantages in
performance, mapping to integrate disparate sources, and tracking changes in dimension attribute values, among others.

Dimensions are often standardized when in a model there are different fact tables associated to different business processes. These standardized dimensions are
known as conformed dimensions and they are shared across the enterprise's datawarehouse environment. Because they join with fact tables from various business
processes, they must either be identical, or a subset of a more detailed dimension. Dimensions can also be degenerate. When a dimension is degenerate it has no
attribute values to describe it. In such cases, a dimensional table is not build for that dimension, but instead it is kept in the fact table, and may be used as
part of the fact table's primary key.

Unlike fact tables, dimensions can change slowly over time. There are different methods for tracking or coping with attribute changes within a dimension, among them are:
\begin{itemize}
	\item Overwriting the old dimension attribute value with the new value.
	\item Adding a new dimension row with the new value.
	\item Adding a new dimension attribute for the old value.
	\item Adding a new dimension
\end{itemize}

% subsection dimensions (end)

\subsection{Operations} % (fold)
\label{sub:operations}

The dimensional model naturally lends itself to certain types of operations that include:

\begin{itemize}
	\item \emph{Slice-and-dice} queries, which are used to reduce a cube. 
	\item \emph{Drill-down and roll-up} queries, which are inverse operations that use dimension hierarchies to provide different levels of granularity for the facts.
	\item \emph{Drill-across} queries, which perform joins on cubes that share one or more dimensions. 
	\item \emph{Ranking or top n/bottom n queries}, which return only cells that appear at the top or bottom of a specified order.
	\item \emph{Rotating a cube}, that allows users to see the data grouped by other dimensions.
\end{itemize}

% subsection operations (end)

\subsection{Implementation} % (fold)
\label{sub:implementation}

Dimensional models can be implemented as Multidimensional (MOLAP), Relational OLAP (ROLAP) or Hybrid (HOLAP) systems. ROLAP systems use
relational database technology for storing data and also employ specialized index structures such as bitmap indices to achieve good
performance. ROLAP servers act as middleware servers between the relational back-end server where the datawarehouse is stored and the
client front-end tools. MOLAP systems act as a native server architecture that does not exploit the functionality of a relational
back-end. MOLAP provide better indexing properties to locate data, with the disadvantage of having poor storage utilization when the
data is sparse. MOLAP servers adapt to sparse data though compression and secondary level storage representation. Finally, HOLAP
architectures combine ROLAP and MOLAP technologies. MOLAP systems tend to perform better when the data is dense, while ROLAP servers
tend to perform better when the data is sparse. Thus, HOLAP identifies dense and sparse regions of data and uses MOLAP and ROLAP
respectively.

% subsection implementation (end)

% section dimensional_modeling (end)

\section{Decision Support Systems} % (fold)
\label{sec:decision_support_systems}

Decision Support is a methodology designed to extract information from data and use it as a basis for decision making. The arrangement
of computerized tools used to assist the managerial decision making within a business is called a decision support system (DSS). A DSS
can be used in various areas within an organization and can be emphasized for solving specific problems. It has three principal
components: a data warehouse server, online analytical processing and data mining tools, and back-end tools for populating the data
warehouse.

% section decision_support_systems (end)

\subsection{Data Warehouses} % (fold)
\label{sub:data_warehouses}

A Data Warehouse (DW) is a database used for reporting on data consolidated by several operational databases. They tend to be
much larger than operational databases, often hundreds of gigabytes to terabytes in size. The dimensional model provides the
logical design used in a data warehouse to manage the information. A data warehouse generally consists of an ETL tool, a
database, a reporting tool and other facilitating tools, such as a Data Modeling tool. It maintains its functions in three
layers: staging, integration, and access. Staging is used to store raw data for use by developers (analysis and support). The
integration layer is used to integrate data and to have a level of abstraction from users. The access layer is for getting
data out for users.

The construction of a data warehouse is a complex process and can take many years, some organizations choose to build data
marts instead. The data mart is a small, single-subject data warehouse subset that supplies decision support to a specific
departmental subset. They serve as a test vehicle for companies that wish to explore the potential benefits of Data
Warehouses. Because they address only local or departmental problems they can involve complex integration problems later.

% subsection data_warehouses (end)

\subsection{Online Analytical Processing and Data Mining Tools} % (fold)
\label{sub:online_analytical_procesing_and_data_mining_tools}

Online analytical processing applications seek to swiftly answer multi-dimensional analytical queries. Queries in OLAP applications
aggregate numeric measures at different levels in dimensional hierarchies. These queries in turn serve the purpose of generating reports
for analysis and data mining. This layer includes a conceptual data model and server architectures. The conceptual data model depends on
dimensions that describe the entities in the transaction. Depending on the logical design some OLAP analysis may involve more complex
statistical calculations than simple aggregations such as sum, count, and average. The server architectures for OLAP can be ROLAP, MOLAP
or HOLAP discussed in \ref{sub:implementation}. Even though traditional relational servers do not efficiently process complex OLAP
queries or support multidimensional data views, three types of relational DBMS servers—relational, multidimensional, and hybrid online
analytical processing—now support OLAP on data warehouses built with relational database systems.

Data mining tools extract patterns and characteristics from data providing advanced predictive and analytical functionality to the DSS.
The process of specifying and achieving a goal through iterative data mining is called Knowledge Discovery. It typically consists of
three phases: data preparation, model building and evaluation, and model deployment.

% subsection online_analytical_procesing_and_data_mining_tools (end)

\subsection{Back-end Tools} % (fold)
\label{sub:back_end_tools}
Populating the datawarehouse from independent data sources involves a process of 3 main phases: Extracting the data from each source,
transforming it to conform to the warehouse schema and cleaning it, and loading it into the warehouse. This process is known as ETL
(Extracting, Transforming and Loading).
The data extraction step consists in bringing data from different sources into a database where they can be modified and incorporated
into the warehouse.

The transformation process uses a set of rules and scripts to transform the data from an input schema to a destination schema
representation. For example, one could have a source that splits a customer's name into three fields: first name, middle
initial, and last name and a datawarehouse schema that only uses one field from customer's name. To incorporate this source
we would have to extract the records and then derive all three attribute values into one value.

Data cleaning consists in fixing errors and differences in schema conventions. These differences may result in inaccurate
query responses and consequently inaccurate mining models. Tools that help with data cleaning address problems such as
duplicate elimination and data cleaning frameworks.

Finally, after the data has been extracted and transformed. It may be necessary to perform additional preprocessing before that data is loaded. In this final
phase, batch load utilities may be used to check the integrity constraints; perform sorting, summarizing and other computations. Derived tables may also be build
to be stored in the datawarehouse. After completing the ETL process, other processes may take place to update the datawarehouse, these include: 
\begin{itemize} 
	\item \emph{Refreshing data}, which consists in propagating updates on the base tables to materialized views and indexes stored in the warehouse.
	\item \emph{Meta-data maintainance}, which consists in updating the definitions, data ownership, and other information required to manage the datawarehouse. 
\end{itemize}

% subsection back_end_tools (end)

\bibliographystyle{plain}
\bibliography{}
\end{document}
